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Abstract 


In  the  Department  of  Defense  (DoD)  acquisition  environment,  many  organizations  have  not 
seriously  considered  adopting  a  product  line  approach  or  are  reluctant  to  because  it  is  not  a 
well-understood  acquisition  paradigm.  Nonetheless,  a  compelling  case  can  be  made  for 
adopting  a  product  line  approach  because  it  addresses  a  problem  facing  many  program 
managers  today — how  to  cost-effectively  acquire,  develop,  and  maintain  a  set  of  related 
software-intensive  systems  and  how  to  respond  to  the  needs  of  greater  product  agility  in  the 
face  of  the  current  DoD  transformation. 

This  technical  note  chronicles  the  decisions  a  program  manager  might  face  in  considering  the 
adoption  of  a  product  line  approach.  This  report  uses  a  hypothetical  acquisition  to  focus  on 
why  an  acquisition  organization  should  consider  adopting  a  product  line  approach — instead 
of  the  traditional  stovepipe  approach — when  acquiring  a  number  of  software-intensive 
systems  that  have  a  lot  in  common.  The  technical  note  provides  a  program  manager  with 
insight  into  the  many  benefits  of  adopting  a  product  line  approach  and  examines  alternative 
acquisition  approaches  for  acquiring  a  product  line  capability. 
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1  Introduction 


Today’s  Department  of  Defense  (DoD)  acquisition  program  managers  (PMs)  must  be  more 
and  more  “software  savvy”  as  they  deal  with  demands  for  software-intensive  systems  with 
greater  capabilities  and  quality,  fielded  in  shorter  time,  and  customized  to  multiple  platforms 
or  situations.  This  situation  is  becoming  increasingly  common,  for  example 

•  A  unit  manager  has  two  legacy  systems  in  dire  need  of  upgrade.  Both  perform  roughly 
the  same  functions  for  different  sets  of  users,  but  software  maintenance  on  each  system 
has  become  a  nightmare.  Their  budget  is  barely  sufficient  for  one  upgrade,  let  alone  two. 

•  A  PM  acquires  a  set  of  software  products  for  other  organizations  that,  in  turn,  integrate 
the  products  as  a  government- furnished  item  (GFI)  to  be  used  as  part  of  a  larger  system. 
Traditionally,  each  product  is  developed  as  a  new  start,  though  they  have  a  lot  in 
common.  How  can  they  cut  costs  and  get  better  delivery  in  terms  of  time  to  field? 

•  A  PM  has  identified  three  customers  from  different  organizations  who  need  systems  or 
upgrades  to  existing  systems  that  have  a  lot  in  common.  Generally,  the  customers  look 
for  unique  systems  to  satisfy  their  needs,  with  no  plans  to  capitalize  on  the  commonality. 
The  PM  cannot  meet  the  acquisition  schedules  or  budgets  for  all  three  systems  in  parallel. 
Instead,  the  PM  shop  must  adopt  systematic  methods  that  will  allow  it  to  field  systems  by 
sharing  software  across  the  three  development  efforts.  How  can  the  PM  develop  a  multi¬ 
system  acquisition  approach  that  will  satisfy  all  three  customers  without  initiating  totally 
unique  acquisitions? 

Issues  in  these  situations  include 

•  How  can  a  DoD  organization  capitalize  on  known  software  commonalities  and 
accommodate  known  variabilities  within  legacy  or  planned  systems? 

•  How  can  a  DoD  organization  work  with  a  supplier(s)  to  build  products  that  share 
software  but  deliver  tailored  capabilities  to  multiple  customers? 

•  How  can  multiple  DoD  organizations  benefit  from  a  contractor’s  software  product  line? 

PMs  must  address  these  issues  to  meet  budgets,  operational  needs,  and  delivery  schedules. 
They  have  multiple  systems  with  common  requirements,  each  satisfying  the  specific 
operational  needs  of  a  particular  unit  or  mission.  Yet  the  PM  wants  to  achieve  delivery  of  the 
systems  without  independent  development  of  essentially  the  same  software  for  each  of  the 
systems.  The  PMs  may  consider  development  from  a  common  set  of  core  software,  but  they 
need  methods  to  develop  the  software  for  the  systems  in  a  prescribed  way.  This  problem 
statement  is  really  a  classic  definition  of  a  software  product  line  [Clements  04].  A  product 
line  approach  allows  a  manager  to  avoid  the  classic  stovepipe  approach  to  acquiring  and 
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maintaining  systems  by  exploiting  commonality  and  managing  variability  across  a  family  of 
systems.  Within  a  product  line,  managers  need  ways  to  determine 

•  what  products  to  develop  to  meet  business  goals  and  future  mission  demands 

•  what  common  software  (or  assets)  to  develop  or  acquire 

•  how  to  develop  or  acquire  the  assets 

•  how  to  develop  or  acquire  the  products 

•  how  to  manage  the  evolution  of  assets  and  products 

In  addition  to  these  technical  concerns,  managers  must  create  a  business  case  [Cohen  0 1  ]  to 
examine  alternative  product  line  approaches  and  to  justify  the  costs  of  developing  the 
software  assets  that  will  be  used  to  develop  derivative  systems  in  the  product  line.  The 
managers  must  also  identify  potential  challenges  and  risks  as  part  of  organizational  planning 
and  risk  management. 

To  help  address  these  issues,  this  technical  note  provides  guidance  on  four  basic  decisions  a 
PM  must  make  in  adopting  a  product  line  approach  for  acquiring  software-intensive  systems: 

1 .  What  is  the  definition  of  the  software  product  line  for  an  organization? 

2.  What  product  line  acquisition  approaches  can  or  should  an  organization  take? 

3.  What  are  the  decisions  a  manager  must  make  in  adopting  the  product  line  approach? 

4.  What  are  the  benefits,  challenges,  and  risks  of  the  product  line  approach? 

This  technical  note  provides  a  hypothetical  example  (see  Section  2)  that  describes  a  typical 
scenario — a  PM  with  several  related  projects:  some  legacy,  some  under  development,  and 
others  planned.  The  PM  is  trying  to  decide  if  adopting  a  product  line  approach  would  be  an 
effective  acquisition  strategy.  The  example  presents  the  questions  a  PM  could  or  should  ask 
about  transitioning  to  a  product  line  approach  for  acquiring  these  products.  Section  3 
identifies  some  of  the  key  decisions  the  PM  must  make  to  cost-effectively  acquire,  develop, 
and  maintain  a  set  of  related  systems.  Section  4  presents  some  alternative  product  line 
acquisition  approaches  for  the  PM  to  consider.  Section  5  outlines  a  course  of  action, 
including  a  set  of  criteria  to  help  the  PM  make  the  initial  product  line  adoption  decisions  and 
provides  a  corresponding  work  breakdown  structure  (WBS)  that  lays  out  a  set  of  tasks  that 
the  PM  shop  and  its  acquisition  organization  should  undertake  when  adopting  a  product  line 
approach.  Section  6  is  a  summary  that  also  identifies  some  follow-on  considerations. 

As  a  cue  to  the  reader,  text  that  pertains  only  to  the  hypothetical  situation 
appears  in  the  Comic  Sans  font,  is  indented,  and  has  a  special  left-hand  bordei — 
as  shown  in  this  paragraph. 
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2  Hypothetical  Organizational  and  System  Context 


A  be  Chapnick  is  a  fictitious  PM  for  a  DoD  organization.  He  oversees  the 
development  of  embedded  systems  (i.e.,  products1)  that  are  deployed  in  a 
number  of  large  command,  control,  and  communication  (C 3)  systems.  His  shop 
manages  system  acquisitions  built  around  battle  space  situational  awareness 
(SA)  and  message  handling  to  update  an  operational  picture  for  the  warfighter. 
These  systems  run  on  a  variety  of  platforms,  and,  if  history  is  any  indicator,  the 
PM  shop  will  be  asked  to  develop  new  systems,  each  built  around  a  common 
operational  picture  (COP).  The  word  “common"  should  be  placed  in  quotes,  Abe's 
shop  often  says,  because  the  current  systems  each  require  its  own  development 
and  maintenance  to  create  and  sustain  the  “common"  picture.  The  PM  shop  has 
an  acquisition  budget  in  the  tens  of  millions  of  dollars  for  new  development  and  a 
maintenance  budget  for  fielded  systems  of  approximately  the  same  size. 

In  the  past  month,  four  different  COP  projects  have  come  to  him  with  the  same 
problem— how  do  we  maintain  the  consistency  of  a  COP  among  the  onboard 
various  combatant  ships,  aviation  platforms,  hand-carried  units,  and  unmanned 
vessels  in  which  our  systems  will  be  deployed?  These  parent  systems  also 
interoperate  with  other  DoD  systems,  sharing  information  and  higher  level  COP 
views. 

After  reviewing  this  problem  for  the  past  month,  Chapnick  decided  to  meet  with 
his  staff  and  come  up  with  a  common,  synergistic  solution. 

“Each  of  your  systems  has  its  own  SA  and  communication-processing  subsystem," 
he  told  the  project  team  leaders  who  were  gathered  around  a  conference  table. 
“Every  time  we  add  information  feeds,  we  go  ahead  and  rewrite  the  onboard 
system  four  times— once  for  each  of  the  combat  information  centers  we 
support— and  then  we  do  the  same  for  the  handheld,  aviation,  and  other 
shipboard  platforms." 

“Make  that  five  times  for  the  vehicles,"  someone  chimed  in  from  the  other  side 
of  the  table.  “Don't  forget  the  unmanned  undersea  vehicle  (UUV)  control 
processing.  Were  scheduled  to  start  working  on  the  software  portion  of  the 
request  for  proposal  (RFP)  next  month." 


1  This  technical  note  uses  the  terms  products  and  software-intensive  systems  interchangeably  because 
the  “products”  in  the  example  product  line  are  software-intensive  systems. 
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"That's  what  I  mean,"  Chapnick  said.  “Why  can't  we  have  a  single  processing 
system,  tailored  to  the  needs  of  each  individual  system?  Then,  when  change 
happens,  we  adjust  the  baseline,  release  it  to  each  system  for  tailoring,  and 
there's  a  single  point  of  maintenance  at  lower  cost  and  greater  reliability." 

Various  objections  were  raised: 

•  One  system  was  inherited  as  a  result  of  program  reorganization  and  had  no 
legacy  of  commonality  with  the  others. 

•  Two  of  the  onboard  systems  have  interfaces  with  unique  databases  and 
have  evolved  their  processing  independently,  even  though  they  follow  the 
same  basic  message-processing  rules. 

•  A  fourth  system  has  SA  capabilities  distributed  among  other  functions. 

•  An  acquisition  authority  was  preparing  an  RFP  for  a  new  system  and,  in 
typical  fashion,  was  not  making  software  a  priority.  They  were  treating  all 
the  UUV  messaging  and  SA  processing  software  as  implementation  specif  ic, 
totally  under  the  purview  of  the  development  contractor. 

No  one  objected  in  principle  to  the  concept  of  a  common  architecture  and 
subsystems.  But  the  project  team  leaders  were  concerned  because  they  had 
been  down  that  path  before,  with  shared  routines,  common  object  libraries, 
frameworks,  and  component-based  solutions,  and  they  had  experienced  only 
marginal  success.  So  imagine  being  in  Abe's  position— you  know  you  can't  continue 
to  maintain  numerous  systems  cost-effectively,  each  using  a  unique  set  of 
components  to  support  SA  through  a  COP,  but  every  software  reuse  approach 
you've  tried  has  not  improved  the  development  or  maintenance  picture.  What 
approaches  could  achieve  improved  results  that  have  not  already  been  tried  and 
rejected? 

In  preparing  for  this  meeting,  Chapnick  had  read  up  on  software  product  lines  as 
a  new  strategic  approach  to  systematic  reuse.  His  analysis  conf  irmed  that  a 
software  product  line  is  an  effective  strategy  to  show  that,  at  the  very  least,  a 
common  architecture  using  SA  and  messaging  processors,  capable  of  tailoring  to 
accommodate  system  specif  ics,  could  be  adopted.  The  architecture  could  be 
retrof  itted  during  major  upgrades  to  some  of  the  legacy  systems  that  were 
already  fielded.  If  properly  written,  the  RFP  for  the  new  UUV  system,  at  least 
the  COP  for  the  controller  side  of  the  vehicle,  could  be  designated  as  the 
source  for  assets  for  a  product  line  of  SA  and  messaging  systems  to  support 
the  UUV  and  other  systems  in  the  PM  shop.  That  would  be  a  tough  sell,  and 
acquisitions  approaches  might  get  in  the  way.  But,  Chapnick's  PM  staff  could 
take  his  initial  analysis,  factor  them  into  planning  for  the  whole  range  of  COP- 
based  systems,  and  explore  acquisition  approaches  to  support  a  long-term 
incremental  strategy. 
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The  next  section  describes  Chapnick's  analysis  and  the  decisions  he  will  face  in 
transitioning  to  a  software  product  line  approach. 
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3  Analyzing  a  Product  Line  Approach 


Chapnick's  analysis  began  with  a  master  schedule  of  systems  (see  Figure  1) 
showing  variation  in  time  (versions)  across  the  space  of  systems  his  shop  must 
develop  or  support.  He  currently  supports  a  legacy  of  systems  for  combat 
information  centers,  a  handheld  device,  and  aviation  platforms.  His  shop  is  also 
working  on  plans  for  new  versions  and  releases  of  these  systems  plus  a  variety 
of  related  systems  for  use  with  UUVs  and  on  aviation  platforms.  Each  of  these 
systems  came  from  different  contractors  and  responded  to  a  variety  of 
requirements,  in  terms  of  performance  specifications  and  interoperability.  For 
example,  the  handheld  is  to  be  used  by  Marine  units.  Aviation  systems, 
currently  under  procurement,  will  interoperate  with  a  variety  of  other  airborne 
and  some  ground  systems.  The  UUV  is  planned  to  come  online  in  2008  to  provide 
autonomous,  semi-autonomous,  and  pure  manual  operations  through  a  handheld 
control  processor.  Chapnick  wants  to  avoid  risks  that  have  plagued  acquisition 
planning  in  the  past  such  as 

•  stovepipe  solutions 

•  proprietary  architectures 

•  potentially  incompatible  technologies 

•  needless  duplication 

•  supplier  lock-in 

•  unpredictable  quality 

•  exorbitant  maintenance  and  support  costs 


This  master  schedule  gave  Chapnick  some  idea  of  the  scope  of  systems  he  was 
supporting  and  acquiring.  They  all  shared  a  number  of  common  capabilities  but 
differed  in  the  mission  coverage— the  COP  of  an  aviation  product  might  cover 
thousands  of  square  miles;  a  handheld  might  cover  only  a  few-mile  radius  but  in 
much  greater  detail.  They  also  differed  in  platform  capabilities— a  combat 
information  center  has  more  computing  resources  to  draw  on  than  an  embedded, 
aviation  product.  The  systems  are  in  different  stages  of  maturity  and 
acquisition.  In  addition,  there's  the  complex  issue  of  supporting  a  system's 
operations  while  planning  for  the  transition  of  future  versions  to  a  product  line 
version. 
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Figure  1:  Schedule  for  Planned  Deployment  of  COP  Systems 


2009 


Chapnick  then  attempted  to  characterize  the  acquisition  approach  currently 
used.  He  concluded  that  existing  systems  were  largely  developed  one  at  a  time, 
with  uniquely  defined  features.  Each  customer  of  the  PM  requires  a  system 
that  addresses  unique  mission  segments  and  user  needs.  Chapnick  had  seen 
reuse  in  the  past— the  “clone  and  own"  approach— where  developers  took  an 
existing  system,  such  as  that  used  in  combat  information  centers,  and  then 
copied  and  modified  it  for  new  uses.  In  fact,  the  handheld  and  shipboard 
developments  were  using  exactly  this  approach.  Finally,  he  knew  that  even 
within  one  development  contractor  organization,  developers  had  adopted 
different  development  practices  and  technologies  with  each  new  system 
resulting  in  unique  solutions.  Table  1  summarizes  Chapnick's  analysis. 
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Systems  Definition 

PM  Acquisition  Today 

System  at  a  time 

COP  products,  each  in  unique 
configurations 

Features  of  each  treated  as  unique 

Features  for  SA  and  tactical  C3  embedded 
in  handheld  and  air  platforms  and  in 
combat  information  centers.  Such  features 
perform 

•  tactical  SA  for  blue,  red,  and  unknown 
forces  and  the  environment 

•  messaging 

•  planning  and  monitoring  the  battle 
space 

Mission  segments  defined  for  each 

C3  for  combat  information  center, 
warf  ighter  handheld,  airborne 

Based  on  legacy  sof  tware 

Cloned  and  owned 

Unique  development  process 

Define  new  approaches,  tools,  and  test  and 
integration  strategies  with  each  new 
system. 

Table  1:  Characterization  of  Current  Acquisition  Approaches  in  Chapnick's 
division 


Next,  Chapnick  focused  on  the  definition  of  a  product  line  to  contrast  the 
current  approach  with  a  product-line-based  acquisition  approach.  A  software 
product  line  is  a  set  of  software-intensive  systems  that  share  a  common, 
managed  set  of  features  satisfying  the  specif  ic  needs  of  a  particular  market 
segment  or  mission  and  that  are  developed  from  a  common  set  of  core  assets  in 
a  prescribed  way  [Clements  02],  Chapnick  parsed  this  definition  into  its 
constituent  parts  to  see  how  the  current  approach,  which  represents  the 
traditional  way  of  doing  business,  aligns  with  a  product  line  approach  (see  Table 
2). 
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Current  (Non-Product-Line) 
Approach 

(Based  on  traditional  planning 
paradigm) 

Product  Line  Approach 

(Based  on  product  line  definition) 

System  at  a  time 

A  set  of  software-intensive  systems 

Features  of  each  treated  as  unique 

That  share  a  common,  managed  set  of 
features 

Mission  defined  for  each 
individually 

(The  systems  must  satisfy) 

the  specif  ic  needs  of  a  selected  market 

segment  or  mission 

Legacy  software  cloned  and  owned 

(And  be)  developed  from  a  common  set  of 
core  assets 

Unique  development  process 

In  a  prescribed  way 

Table  2:  Contrast  of  Approaches:  Current  (Non-Product-Line)  and  Product 
Line 


Finally,  Chapnick  wished  to  compare  how  the  ongoing  development  activities  of 
the  PM  shop  today  would  differ  from  the  development  activities  under  a 
software  product  line  approach  (see  Table  3). 
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Product  Line  Definition 

Acquisition  Today  Under 
PM  Shop 

PM  Shop  After  Product  Line 
Adoption 

A  set  of  software-intensive 
systems 

COP  products  individually 
acquired  in  all  current 
configurations 

Common  set  of  COP  products 
in  all  current  and  planned 
configurations 

That  share  a  common, 
managed  set  of  f  eatures 

Features  replicated  for 

COP  embedded  in  shipboard 
and  air  platforms  and  in 
command  centers.  Such 
features  perform 

•  tactical  SA  for  blue, 
red,  and  unknown 

f  orces  and  the 

environment 

•  messaging 

•  planning  and  monitoring 
the  battle  space 

Features  tailored  for  tactical 
C3  embedded  in  shipboard 
and  air  platforms  and  in 
combat  information  centers 
and  for  Marine  units.  Such 
features  perform 

•  tactical  SA  for  blue,  red, 
and  unknown  forces  and 
the  environment 

•  messaging 

•  planning,  monitoring,  and 
managing  the  battle  space 

(The  systems  must  satisfy) 
the  specif  ic  needs  of  a 
selected  market  segment 
or  mission 

COP  requirements  for 
selected  missions  based  on 
system  specif  ics 

COP  for  battlefield 
operations  tailored  for 
various  echelons:  Marine  C3, 
aviation,  self-protection, 
combat  information  centers, 
and  UUV 

(And  be)  developed  from  a 
common  set  of  core  assets 

limited  potential  for 
opportunistic  reuse  if  same 
contractors  are  involved 

Common  display,  prebuilt 
applications,  scripts  for 
production  builds 

In  a  prescribed  way 

“Clone  and  own"  (i.e.,  take 
existing  system,  make 
modif  ications,  and  maintain 
new  version  as  separate 
system) 

Processes  for 

•  development  and 
maintenance  of  core 
assets  and  products 

•  production  plan  for  COP 
systems  in  product  line 

•  configuration 
management  plan  for 
core  assets  and  products 
in  the  product  line 

Table  3:  Implications  of  Transition  to  a  Product  Line  Approach 
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I  At  this  point  in  the  analysis,  Chapnick  had  already  made  a  few  decisions  about 
some  basic  questions: 

•  What  was  the  scope  of  the  product  line? 

He  knew  the  product  line  as  defined  by  the  set  of  products  under  current  or 
planned  acquisitions. 

•  Was  there  a  sufficient  market  to  justify  a  product  line  approach? 

He  knew  his  market  or  mission  segment  based  on  the  need  for  one  new  system 
per  year. 

•  Could  he  characterize  the  domains? 

He  knew  that  SA  and  messaging  were  key  areas  of  expertise  that  could  be 
captured  within  the  product  line.  The  COP-based  product  line  would  also  require 
human-computer  interaction  (HCI)  expertise. 

•  Was  there  a  business  case? 

Chapnick  knew  he'd  have  to  justify  such  a  departure  from  the  old  way  of 
acquiring  systems  using  a  business  case.  But  the  ability  to  maintain  a  number  of 
systems  from  a  single,  common  baseline  seemed  very  appealing  and  compelling, 
even  if  a  signif  icant  investment  was  needed  to  exploit  the  potential. 

•  Could  a  common  architecture  sustain  the  variability  across  the  product  line? 

Chapnick  considered  ways  to  craft  an  RFP  to  see  what  solutions  potential 
contractors  could  come  up  with  including  the  current  legacy  system  developers. 

•  What  processes  were  needed  to  support  product  line  development? 

Chapnick  had  identified  several  key  processes  when  he  looked  at  the  transition 
he'd  need  to  make  (Table  3)  including  ones  for 

-  acquisition  for  the  development  and  maintenance  of  core  assets  and  products 

-  PM  activities  commensurate  with  a  contractor's  production  plan  for  developing 
COP  systems  in  the  product  line 

-  conf iguration  management  for  core  assets  and  products  in  the  product  line 


Chapnick  still  needed  to  come  up  with  the  acquisition  approach— his  strategy  for 
acquiring  core  assets  to  share  across  the  product  line  and  for  use  in  building 
derivative  products.  The  new  U&V  RFP  presented  some  fascinating 
opportunities  and  challenges— development  of  a  business  case,  technology 
forecasting,  and  other  artifacts— that  he  would  explore  with  his  own  staff  and 
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other  individuals  supporting  the  acquisition.  He'd  also  draw  on  their  expertise  in 
cost  estimation  to  craft  a  business  case.  He  may  not  have  had  a  complete 
roadmap  yet,  but  at  least  he  had  a  destination. 

Chapman  did  some  research  on  these  considerations  and  others  that  were 
puzzling  him  by  visiting  the  Carnegie  Mellon®  Software  Engineering  Institute 
(SEI)  Web  site2  and  reading  some  of  the  publications  he  found  there  on 
software  product  lines.  These  reports  included  a  case  study  of  a  DoD  product 
line  acquisition  initiative  [Clements  05]  and  a  technical  note  [Jones  99]  that 
presents  the  basics  of  product  line  practices  and  reports  the  results  of  two 
DoD  product  line  workshops  in  which  important  issues  and  successful  practices 
were  shared.  That  technical  note  also  provides  other  examples  and  sources  of 
pertinent  information  in  its  “References"  section. 


The  next  section  of  this  report  focuses  on  acquisitions  approaches  that  any  PM  must  consider. 


'  Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon 
University. 

2  http://www.sei.cmu.edu/productlines/index.html 
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4  Possible  Product  Line  Acquisition  Approaches 


A  PM  needs  to  consider  a  number  of  alternative  acquisition  approaches  when  contemplating 
adopting  a  product  line  approach.  Three  such  approaches  that  are  suitable  for  use  by  DoD 
organizations  (and  other  government  agencies)  are 

1.  Commission  a  government  organization  to  develop  the  product  line.  This  strategy 
involves  acquiring  a  completely  government-owned  product  line  using  the  in-house 
capabilities3  of  a  designated  government  acquisition  organization. 

2.  Commission  one  or  more  suppliers  to  develop  the  product  line.  This  strategy 
involves  acquiring  a  complete  product  line  production  capability4  and  developing 
derivative  products  by  contracting  with  one  or  more  suppliers. 

3.  Commission  a  supplier  to  develop  products  using  its  own  product  line.  This  strategy 
involves  acquiring  products  directly  from  a  supplier  that  has  an  existing  product  line  and 
a  demonstrated  capability  to  build  derivative  products. 

A  PM  must  carefully  consider  these  alternative  approaches  and  the  implications  of  each  in 
terms  of  organizational  sophistication.  In  addition,  he  must  address  these  questions: 

•  Does  the  PM  shop  have  the  experience,  resources,  skills,  and  commitment  needed  to 
implement  the  selected  approach? 

•  Is  the  designated  acquisition  organization  capable  of  implementing  and  managing  the 
selected  approach  for  RFP  preparation,  funding,  source  selection,  contract  deliverables, 
and  technical  oversight? 

•  Will  program  managers’  technical  and  acquisition  expertise  be  adequate  to  deal  with  the 
corresponding  acquisition  complexities  and  data-rights  issues  implicit  in  the  approach 
they  choose  for  delivering  products  to  their  customers? 

These  acquisition  approaches  are  summarized  in  the  following  sections  and  include 
illustrative  examples  of  the  DoD  and  government  projects  that  implemented  them. 


3  In  this  approach,  acquisition  is  limited  to  using  local  support  contractors  or  Systems  Engineering  and 
Technical  Assistance  (SETA)  contractors. 

4  This  capability  would  include  acquiring  the  core  assets  (e.g.,  the  architecture,  software  components, 
production  plan)  and  other  artifacts  that  the  government  would  need  to  operate,  sustain,  and  enhance 
the  product  line  capabilities  and  develop  additional  products. 
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4.1  Commission  a  Government  Organization  to  Develop  the 
Product  Line 

In  this  approach,  a  PM  negotiates  an  agreement  to  have  an  acquisition  organization  develop 
the  product  line.  That  organization  is  responsible  for  developing  the  core  assets  and  a  suitable 
product  line  production  infrastructure.  The  result  is  a  completely  government-owned  product 
line  production  capability  that  the  acquisition  organization  can  subsequently  use  to  build  and 
manage  derivative  products  under  the  oversight  of  the  PM  shop.  This  approach  is  not 
commonly  used  today  because  most  acquisition  organizations  lack  the  resources  and  skills 
needed  to  carry  it  out. 

Two  variations  of  this  approach  should  be  considered: 

1.  The  product  line’s  core  assets  and  the  products  built  from  them  are  exclusively 
developed  and  managed  by  elements  of  the  acquisition  organization  in  accordance  with 
the  PM’s  direction.  Once  delivered,  the  PM  and  customer  may  share  the  task  of 
maintaining  the  product. 

One  example  of  this  approach  is  the  development  of  a  software  product  line  asset  base 
called  Range  Ware,  which  the  Naval  Undersea  Warfare  Center  (NUWC),  Division 
Newport  developed  to  support  test  range  operations  [Cohen  02],  After  several  pilot 
applications  of  RangeWare,  NUWC  is  now  taking  RangeWare  into  a  sustainment  phase, 
expanding  coverage  of  the  asset  base  and  applying  the  assets  to  new  systems.  NUWC 
handles  maintenance  through  a  cost-sharing  agreement  with  its  customers  and  uses 
customer  experience  to  improve  the  asset  base  for  future  product  line  products. 

2.  The  product  line  asset  base  and  one  or  more  initial  systems  (i.e.,  products)  are  developed 
initially  by  the  acquisition  organization  with  PM  oversight.  As  the  product  line  matures, 
the  PM  has  the  option  of  transitioning  the  asset  base  to  a  contractor  for  use  in  developing 
other  new  systems. 

This  is  the  approach  that  the  Software  Engineering  Center  (SEC)  at  the  U.S.  Army’s 
Communications  and  Electronics  Command  (CECOM)  is  taking  in  developing  a  product 
line  for  its  Advanced  Multiplex  Test  System  (AMTS).  The  AMTS  implements 
standardized  test  methods  and  procedures  for  electronic  systems  that  use  the  MIL- STD- 
1553  data  bus  [CECOM/LRC  02],  Once  the  product  line  is  fully  mature,  the  SEC  plans 
to  transition  the  development  and  sustainment  of  the  product  line  to  one  or  more 
contractors. 
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4.2  Commission  One  or  More  Suppliers  to  Develop  the  Product 
Line 

In  this  approach,  PMs  prepare  an  RFP — with  help  from  their  acquisition  organization — for  a 
competitive  contract  to  have  a  supplier  develop  a  complete  product  line  capability.  The 
supplier  assumes  responsibility  for  developing  the  asset  base  and  building  the  products 
specified  in  the  contract  or  included  as  future  options.  The  PMs  would  require  government- 
use  data  rights  for  all  the  contract  deliverables  that  would  include  the  asset  base,  essential 
elements  of  the  production  infrastructure,  and  products  built  from  the  asset  base. 

Two  basic  variations  of  this  collaborative  acquirer/supplier  approach  should  be  considered: 

1.  A  single  contractor  develops  the  core  assets,  maintains  the  asset  base,  and  builds 
derivative  products.  This  approach  has  the  benefit  of  avoiding  problems  stemming  from 
conflicting  business  interests  that  often  arise  when  multiple  contractors  are  involved. 

A  striking  and  very  successful  application  of  this  approach  is  the  Control  Channel 
Toolkit  (CCT),  a  software  asset  base  for  a  software  product  line  of  ground-based 
spacecraft  command-and-control  systems  built  under  the  direction  of  the  National 
Reconnaissance  Office  (NRO)  [Clements  01].  The  contractor  that  built  the  asset  base 
was  also  the  one  (i.e.,  user)  that  developed  the  initial  products  using  it.  Nothing  would 
preclude  the  NRO  from  providing  the  CCT  as  a  GFI  to  other  contractors  that  were 
commissioned  to  build  spacecraft  command-and-control  systems  by  the  NRO  or  another 
government  office.  Electing  such  a  course  of  action  would  correspond  to  the  next 
approach  described. 

2.  A  prime  contractor  develops  and  maintains  the  core  asset  base,  and  other  contractors 
build  and  maintain  products  using  the  core  assets  developed  by  the  prime  contractor.  In 
this  approach,  the  asset  base  developed  by  the  prime  contractor  is  a  deliverable  to  the 
PM  shop  (or  its  acquisition  organization)  and  is  provided  as  a  GFI  to  other  contractors 
for  use  in  building  products.  A  complicating  factor  is  that  this  approach  thrusts  the 
government  into  the  role  of  being  the  system  integrator.  One  approach  for  overcoming 
the  potential  problems  that  can  arise  from  this  arrangement  is  for  the  PM  shop  to  let  a 
single  contract  to  a  lead  system  integrator  (LSI).  The  LSI,  in  turn,  is  responsible  for 
contracting  with  other  suppliers  (e.g.,  domain  experts)  to  develop  derivative  products 
using  the  asset  base  developed  by  the  LSI  (or  another  supplier  commissioned  by  the 
LSI).  Clements,  Bergey,  and  Mason  describe  an  example  software  development  plan 
(SDP)  for  a  DoD  project  that  adopted  such  an  approach  [Clements  05]. 
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4.3  Commission  a  Supplier  to  Develop  Products  Using  Its  Own 
Product  Line 

In  this  approach,  a  PM  does  not  have  to  commission  a  supplier  to  develop  a  core  asset  base  in 
order  to  realize  the  benefits  of  a  product  line  approach.  Instead,  the  PM  lets  a  competitive 
contract  to  acquire  products  from  a  supplier  with  an  existing  product  line  capability  that 
includes  an  extensible  core  asset  base  relevant  to  the  PM’s  application  domain.  Before 
committing  to  this  course  of  action,  the  PM  should  first  perform  a  market  analysis  or 
formally  issue  a  request  for  information  (RFI)  to  determine  that  such  an  approach  is  truly 
viable.  One  concern  associated  with  this  approach  is  that  the  PM  may  not  have  as  much  clout 
in  driving  the  product  requirements  and  in  how  the  product  line  evolves.  As  a  result, 
government  customers  may  want  to  consider  forming  a  users’  consortium  to  exert  greater 
influence  on  the  future  direction  of  the  product  line.  Another  concern  is  that  government  data 
rights  would  need  to  be  negotiated  due  to  the  proprietary  nature  of  a  supplier-owned  product 
line,  but  this  is  not  a  show-stopper. 

Two  basic  variations  of  this  unique  supplier-centric  approach  should  be  considered: 

1.  A  single  product  is  acquired  directly  from  a  supplier  that  builds  the  product  using  its 
own  proprietary  product  line  production  capability.  Any  follow-on  products  are 
acquired  via  a  separate  acquisition  or  as  an  option  in  the  original  contract  that  can  be 
exercised  at  the  government’s  discretion.  Such  an  acquisition  can  be  an  effective  way  to 
realize  the  reduced  cost  and  predictable  delivery  and  product  quality  that  a  product  line 
provides. 

CelsiusTech  Systems  AB  of  Sweden,  a  developer  of  large,  complex,  embedded,  real¬ 
time  shipboard  command-and-control  systems,  positioned  itself  along  these  lines.  By 
implementing  a  product  line  approach,  Celsius  Tech  found  it  could  support  its  existing 
customer  base  and  accommodate  new  customers,  while  improving  its  ability  to  market 
and  deliver  new  systems  with  a  reasonably  certain  schedule,  cost,  and  required 
functionality  [Brownsword  96]. 


2.  Multiple  products  (i.e.,  a  preplanned  family  of  related  products)  are  acquired  directly 
from  a  supplier  that  has  an  existing  product  line  production  capability  with  an  extensible 
asset  base.  This  acquisition  strategy  is  predicated  on  letting  an  indefinite  delivery, 
indefinite  quantity  (IDIQ)  contract  that  includes  funding  for  the  first  product  and 
provisions  and  options  for  acquiring  multiple  products  within  the  projected  scope  of  the 
supplier’s  product  line. 

The  U.S.  Army’s  Technical  Applications  Program  Office  (TAPO)  adopted  such  a 
product  line  approach  to  reduce  development,  maintenance,  and  integration  costs  for 
upgrading  the  avionics  software  for  the  Army’s  fleet  of  special  operations  helicopters 
[Clements  05].  This  product  line,  which  is  based  on  Rockwell  Collins’  Common 
Avionics  Architecture  System  (CAAS),  is  now  evolving  beyond  special  operations  and 
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being  expanded  to  include  Army  aviation  at  large  and  other  DoD  rotary  wing  aircraft. 
Rockwell  Collins  proactively  pursued  a  product  line  approach  to  address  new  business 
opportunities  in  a  way  that  would  significantly  lower  the  cost  of  developing  new 
software  systems  and  give  it  a  competitive  edge  in  the  marketplace. 

Other  aspects  that  a  PM  should  consider  in  selecting  a  strategy  for  acquiring  a  product  line — 
especially  as  they  relate  to  DoD  policy  and  the  acquisition-program  life  cycle — are  described 
in  more  detail  by  Campbell  [Campbell  02].  And  a  case  study  of  an  example  approach  for 
developing  a  product  line  acquisition  strategy  for  a  DoD  organization  is  described  by  Bergey 
and  Goethert  [Bergey  01].  That  case  study  focuses  on  how  one  DoD  organization  answered 
these  questions:  “What  does  developing  an  acquisition  strategy  involve?”  and  “How  does  a 
DoD  organization  develop  an  effective  strategy  for  acquiring  a  software  product  line?” 


4.4  Considerations  in  Selecting  an  Acquisition  Approach 

PMs  must  establish  a  clear  set  of  roles  and  responsibilities  for  what  the  PM  shop  must  take 
on  (or  contract  for) — whichever  approach  they  select.  Key  roles  and  responsibilities  are  in 
the  following  areas: 

•  core  asset  development.  Responsibilities  include 

-  the  mining  and  reengineering  of  legacy  assets 

-  new  asset  development  (e.g.,  architecture,  core  components,  production  plan) 

•  core  asset  sustainment  and  the  development  of  new  core  assets.  Responsibilities  include 
the 

-  maintenance  and  enhancement  of  existing  assets 

-  development  of  new  assets  (e.g.,  components,  test  cases,  documentation  artifacts) 

•  product  development  and  sustainment.  Responsibilities  include 

-  product  definition 

-  asset  selection  and  tailoring 

-  product  production 
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Figure  2  illustrates  the  key  areas  where  collaborative  roles  and  responsibilities  have  to  be 
suitably  defined  for  the  DoD  and  contractor  organizations  commensurate  with  the  product 
line  approach  that  is  adopted. 
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Figure  2:  Key  Areas  for  Defining  Roles  and  Responsibilities  of  the  DoD  and 
Contractor  Product  Line  Organizations 


A  PM  must  also  tailor  the  selected  acquisition  approach  to  accommodate  the  needs  of  the  PM 
shop  commensurate  with  its  ability  to  acquire  and  manage  a  product  line.  Table  4  provides 
some  rule-of-thumb  indicators  for  how  the  different  acquisition  approaches  will  affect  a  PM’s 
choice,  given  these  considerations. 
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Product  Line 

Acquisition  Approach 

Relative  Degree  of 
Organizational 
Sophistication 
Needed  by  Acquirer 

Relative 

Degree  of 

Acquisition 

Complexity 

Typical  Scope  of 
Data  Rights 

l.a  Development  by 

acquisition  organization 

high 

low 

Complete 
data  rights 

1  .b  Development  by 

acquisition  organization 
and  transitioned  to 

contractor 

high 

medium 

2. a  Development  involves 
one  supplier 

high 

high 

Complete 

government-use  data 
rights 

2.b  Development  involves 
multiple  suppliers 

very  high 

very  high 

3. a  Single-product 
development  using 
supplier-owned  product 
line 

low 

low 

Negotiated 
government-use 
data  rights 

3.b  Multiple-product 
development  using 
supplier-owned  product 
line 

low 

medium 

Table  4:  Impact  of  Selecting  a  Particular  Acquisition  Approach 
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5  Guidance  for  Key  Decisions  Regarding  Product  Line 
Adoption 


Next,  PMs  must  consider  the  decisions  they  must  make  to  get  the  product  line  approach 
launched  in  the  PM  shop.  They  must  also  provide  a  corresponding  WBS  that  lays  out  the  set 
of  tasks  their  PM  shop  will  undertake  to  adopt  a  product  line  approach  in  their  acquisition 
organization.  Table  5  illustrates  the  kinds  of  decisions  the  PMs  must  make  and  the  criteria 
they  should  use  when  making  them. 


Decision 

Purpose 

Criteria 

Timing  and 
Dependencies 

Results 

Scope 

To  set  bounds 
on  the  products 
the  PM  will  be 
able  to  build 
from  the  product 
line 

PM’s  experience 

Earliest  decision 

Drives  business 
case  and 
acquisition 
approach 

Market 

To  understand 
the  needs  of  the 
customer  base 
and  the  ability 
of  the  PM  shop 
to  meet  them 

Numbers  of 
products  per 
year  for  the 
range  of  current 
and  future 

customers 

Developed 
jointly  with  the 
scope 

Drives  business 
case  and 
acquisition 
approach 

Domains 

To  understand 
the  product  line 
assets  needed  to 
build  the 
product  line 

Technical 
experience  and 
technology 
forecast.  What 
can  be  built 
versus  what  can 
be  mined  versus 
what  can  be 
bought  or 
commissioned. 

Based  on  the 
scope 

Specifies 
commonality 
and  variability 
across  products 
that  are  within 
scope 

Business  case 

To  characterize 
the  benefits  and 
risks  of 
alternative 
approaches 

Cost  benefit 
analysis 

Based  on  the 
scope,  domain 
understanding, 
and  review  of 
acquisition 
alternatives 

Provides  data 
for  a  go/no-go 
decision  for  the 
product  line 

Table  5:  Decisions  in  Adopting  a  Product  Line  Approach 


20 


CMU/SEI-2006-TN-020 


Decision 

Purpose 

Criteria 

Timing  and 
Dependencies 

Results 

Acquisition 

approach 

To  address  the 
production 
strategy  and 
acquire  core  assets 
and  products 

Sophistication 
of  the  PM  shop 
in  both  technical 
and  managerial 
areas 

Based  largely  on 
the  scope, 
market,  and 
analysis  of 
alternative 
acquisition 
strategies 

Is  incorporated 
into  the  business 
case  to  weigh 
possible 
alternatives 

Training 

To  ensure  that  the 
PM  shop 
understands  the 
basic  concepts  of 
the  product  line 
approach  and  the 
roles  played  by 
each  participant 

Sophistication 
of  the  PM  shop 
in  both  technical 
and  managerial 
areas 

To  understand 
product  lines,  all 
participants 
need  training  in 
basic  product 
line  concepts. 

To  execute 
product  lines, 
select  individ¬ 
uals  need 
training  in 
advanced 
product  line 
concepts. 

Staff  is  trained 
to  work  with 
contractors  and 

customers. 

Architecture 

definition 

To  create  the 
structure  for  the 
construction  of  all 
future  components 
and  products  in  the 
product  line 

Scope,  domain 
understanding, 
and  design 
constraints 

Dependent  on 
the  scope, 
commonalities/ 
variabilities,  and 
design  expertise 

PM  reviews  the 
designs  for 
structuring  the 
product  line  and 
the  component 
assets  to  be  used 
in  building 
products. 

Processes 

To  guide  all 
operations 
(technical  and 
management) 
within  the  PM 
shop  and 
contractors 

Existing 
development 
and  acquisition 
processes; 
product  line 
framework 
practice  areas 
[Clements  04] 

Based  on  the 
scope, 
acquisition 
approach,  and 
concept  of 
operations  for 
the  product  line 
roles  and 
responsibilities 

PM  reviews 
processes 
proposed  and 
adopted  by 
contractors  for 
creating  the 
asset  base  and 
using  it  to  build 
products. 

Table  5:  Decisions  in  Adopting  a  Product  Line  Approach  (cont’d.) 
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Decision 

Purpose 

Criteria 

Timing  and 
Dependencies 

Results 

Customer 

interface 

management 

To  create 
effective  ways 
to  work  with 
new  or  existing 
customers  under 
the  product  line 
approach 

Ongoing 

working 

relationships, 

customer 

satisfaction, 

growth  areas 

Based  on  the 
scope 

Provides  inputs 
to  the  business 

case 

Identification  of 
the  groups  or 
individuals 
responsible  for 
interfacing  with 
customers 

Assignment  of 
roles  and 
provision  of 
training 

Production 
strategy > 

To  provide 
overall  guidance 
for  creating  and 
sustaining  the 
asset  base  and 
using  the  asset 
base  to  build 
products 

Scope,  domain 
understanding, 
and  acquisition 
approach 

Dependent  on 
early  knowledge 
of  the  asset  base 
structure  and 
acquisition 
approach 

PM  reviews 
proposed 
processes  to 
create  the  asset 
base  and 
generate  a 
production  plan 
for  building 
future  products 

Table  5:  Decisions  in  Adopting  a  Product  Line  Approach  (cont’d.) 


These  activities  and  decisions  are  described  in  more  detail  in  the  Software  Product  Line 
Acquisition:  A  Companion  to  A  Framework  for  Software  Product  Line  Practice  developed  by 
the  SEI  [Bergey  04,  Clements  04], 

Chapnick  factored  the  product  line  decisions  into  a  WBS  to  lay  out  tasks  for  his 
PM  shop  to  undertake  (see  Figure  3). 
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ID 

Task  Name 

1 

Determine  what  to  build 

2 

Scope  product  line 

7 

Maintain  product  line  scope 

8 

Develop  marketing  plan 

12 

Understand  domains 

17 

Build  business  case 

23 

Maintain  business  case 

24 

Determine  acquisition  strategy 

25 

Develop  RFP 

26 

Release  RFP 

27 

Track  success 

30 

Develop  structure  &  processes 

38 

Define  architecture 

42 

Determine  production  strategy 

43 

Training 

44 

July  |  SepterfNovem  Januar  March  May  |  July  jSepten 


Figure  3:  WBS  for  the  Initial  Tasks  for  the  PM's  Product  Line  Initiative 


His  next  goal  would  be  to  apply  resources  to  these  tasks,  once  the  business  case  is 
approved  by  his  management  chain  and  the  program  executive  off icer  (PEO).  At  that 
point,  Chapnick  will  have  launched  his  product  line. 
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6  Summary  and  Follow-On  Considerations 


A  compelling  case  can  often  be  made  for  adopting  a  product  line  approach  because  it 
addresses  a  problem  facing  many  PMs  today — how  to  cost-effectively  acquire,  develop,  and 
maintain  a  set  of  related  software-intensive  systems.  Managers  can  easily  recognize  the 
potential  of  capitalizing  on  commonality  across  the  systems  they  support  through  a  product 
line  approach.  However,  they  lack  guidance  on  the  decisions  they  need  to  make  about  the 
product  line  approach  and  on  the  information  they  need  to  assemble  to  make  these  decisions. 
The  hypothetical  acquisition  scenario  that  is  described  is  the  basis  for  providing  generic 
guidance  for  the  activities  a  PM  shop  should  pursue  when  considering  adopting  a  product  line 
approach.  The  technical  reports  and  case  studies  cited  under  the  alternative  acquisition 
approaches  provide  additional  information  for  the  PM  shop  to  consider  when  choosing  the 
course  of  action  that  is  best  suited  to  its  needs  and  those  of  its  customers. 

Another  approach  not  discussed  in  this  report  is  to  have  an  outside  organization  conduct  a 
product  line  diagnosis  to  evaluate  a  PM  shop’s  (or  supplier’s)  ability  to  launch  a  product  line 
initiative.  The  SEI,  with  its  Product  Line  Quick  Look5  and  Product  Line  Technical  Probe,6  is 
just  one  organization  that  provides  product  line  diagnoses.  If  the  diagnoses  show  that  there  is 
potential  for  a  product  line  approach,  a  plan  should  be  developed  that  addresses  identified 
shortcomings  and  capitalizes  on  organizational  strengths. 


5  For  more  information,  go  to  http://www.sei.cmu.edu/productlines/plql.html. 

6  For  more  information,  go  to  http://www.sei.cmu.edu/productlines/pltp.html. 
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